헤더 보안

Content Security Policy(CSP)는 웹 애플리케이션이 로드할 수 있는 리소스의 출처를 제한함으로써 XSS(크로스 사이트 스크립팅)와 같은 코드 삽입 공격을 효과적으로 완화하는 핵심 헤더 보안 정책이다. 서버가 Content-Security-Policy HTTP 응답 헤더를 통해 정책을 브라우저에 전달하면, 브라우저는 해당 정책에 따라 스크립트, 스타일시트, 이미지, 폰트 등 모든 리소스의 로드를 제어한다.

CSP의 기본 원칙은 화이트리스트 방식이다. 웹 개발자는 신뢰할 수 있는 도메인, 프로토콜, 포트만을 정책으로 명시하며, 정책에 명시되지 않은 출처에서의 리소스 로드는 브라우저에 의해 차단된다. 예를 들어, 스크립트의 출처를 자신의 사이트 도메인으로만 제한하면, 공격자가 악성 스크립트를 삽입하더라도 해당 스크립트가 외부에서 로드되거나 인라인으로 실행되는 것을 방지할 수 있다.

주요 지시어(directive)로는 default-src, script-src, style-src, img-src, connect-src, font-src, frame-src 등이 있다. default-src 지시어는 다른 지시어들에 대한 기본 출처를 정의하며, 구체적인 리소스 유형별로 더 엄격한 정책을 별도로 설정할 수 있다. 또한 'self', 'none' 같은 키워드나 https: 같은 프로토콜 스킴을 사용하여 정책을 세밀하게 구성한다.

CSP를 도입할 때는 Content-Security-Policy-Report-Only 헤더를 먼저 사용하여 정책을 시범 적용하는 것이 권장된다. 이 모드에서는 정책 위반 사항을 차단하지 않고 지정된 URL로 보고만 전송하므로, 기존 서비스에 영향을 주지 않으면서 정책의 적합성을 검증할 수 있다. OWASP는 CSP를 XSS 방어를 위한 가장 효과적인 방어 메커니즘 중 하나로 강력히 권고하고 있다.

HTTP Strict Transport Security (HSTS)는 웹사이트가 HTTPS를 통해서만 접근해야 함을 사용자의 웹 브라우저에 지시하는 보안 정책이다. 이 정책은 HTTP로의 접속 시도를 자동으로 보안이 강화된 HTTPS 연결로 강제 전환하도록 브라우저에 명령함으로써, 중간자 공격과 같은 보안 위협을 방지하는 데 목적이 있다.

HSTS는 Strict-Transport-Security라는 HTTP 응답 헤더를 통해 설정된다. 이 헤더에는 max-age 지시어가 필수적으로 포함되어야 하며, 이는 브라우저가 해당 사이트를 HSTS 호스트 목록에 얼마 동안 저장할지를 초 단위로 지정한다. 예를 들어, max-age=31536000은 1년 동안 정책을 유지하도록 설정한다. 선택적으로 includeSubDomains 지시어를 추가하면 모든 하위 도메인에도 동일한 정책이 적용되며, preload 지시어는 주요 브라우저의 사전 로드 목록에 포함되도록 요청하는 기능이다.

이 정책의 핵심 이점은 첫 번째 방문 이후 발생하는 보안 강화에 있다. 사용자가 처음 사이트를 방문할 때 서버가 HSTS 헤더를 보내면, 브라우저는 지정된 기간 동안 해당 정보를 기억한다. 이후 사용자가 URL에 http://를 입력하거나 일반 링크를 클릭하더라도 브라우저는 내부적으로 이를 https://로 변환하여 연결을 시도한다. 이 과정은 사용자에게 보이지 않게 이루어지므로, 실수로 발생할 수 있는 암호화되지 않은 연결을 근본적으로 차단한다.

HSTS는 특히 세션 쿠키 하이재킹이나 SSL 스트리핑 공격과 같은 중간자 공격을 효과적으로 완화한다. 그러나 주의할 점은, 최초 접속 시에는 여전히 일반 HTTP 연결이 가능하기 때문에 SSL/TLS 인증서 오류나 초기 설정 문제가 발생할 수 있다는 것이다. 따라서 HSTS는 강력한 SSL/TLS 구성과 함께 적용되어야 완전한 효과를 발휘하는 보안 레이어로 간주된다.

X-Content-Type-Options는 브라우저의 MIME 스니핑 동작을 제어하는 HTTP 응답 헤더이다. 이 헤더의 유일한 유효한 값은 nosniff이며, 서버에서 명시적으로 선언한 콘텐츠 타입을 브라우저가 재해석하지 못하도록 차단하는 역할을 한다.

웹 브라우저는 종종 서버가 제공한 Content-Type 헤더를 신뢰하지 않고 콘텐츠를 직접 분석하여 파일의 실제 유형을 추측하는 MIME 스니핑을 수행한다. 이는 호환성을 위해 설계된 기능이지만, 악의적으로 조작된 파일이 다른 유형으로 해석되어 실행될 수 있는 보안 취약점을 만들 수 있다. X-Content-Type-Options 헤더를 nosniff로 설정하면 브라우저가 이 스니핑 동작을 수행하지 않도록 강제한다.

이 헤더는 주로 스타일시트와 자바스크립트 파일에 대한 MIME 스니핑 공격을 방어하는 데 효과적이다. 예를 들어, 공격자가 이미지 파일로 위장한 악성 스크립트를 업로드하고 서버가 이를 잘못된 Content-Type으로 제공할 경우, 브라우저가 스니핑을 통해 이를 스크립트로 인식하고 실행하면 크로스 사이트 스크립팅 공격이 발생할 수 있다. nosniff 지시어는 브라우저가 선언된 타입을 엄격하게 따르게 함으로써 이러한 위험을 차단한다.

X-Content-Type-Options는 OWASP가 권장하는 핵심 보안 헤더 중 하나로, 웹 애플리케이션 방화벽이나 CDN 설정을 통해서도 쉽게 적용할 수 있다. 그러나 이 헤더만으로 모든 MIME 관련 공격을 완전히 차단할 수는 없으며, 서버 측에서 올바른 Content-Type을 제공하는 것과 함께 다른 웹 보안 정책들과 함께 적용되어야 한다.

X-Frame-Options는 웹 브라우저가 HTML 문서를 프레임, iframe, 오브젝트, 임베드 태그 내에서 렌더링할 수 있는지를 제어하는 HTTP 응답 헤더이다. 이 헤더의 주요 목적은 클릭재킹 공격을 방어하는 것이다. 클릭재킹은 공격자가 투명한 레이어나 프레임을 사용해 사용자가 의도하지 않은 버튼이나 링크를 클릭하도록 속이는 공격 기법이다.

이 헤더는 세 가지 주요 지시어를 사용한다. DENY 지시어는 페이지를 어떤 프레임 내에서도 표시하지 않도록 완전히 차단한다. SAMEORIGIN 지시어는 페이지가 자신과 동일한 오리진을 가진 사이트의 프레임 내에서만 표시되도록 허용한다. ALLOW-FROM uri 지시어는 특정한 URI로 지정된 사이트의 프레임 내에서만 페이지를 표시하도록 허용하지만, 이 옵션은 일부 브라우저에서 지원되지 않는다.

X-Frame-Options는 웹 서버 설정 파일(예: Apache의 .htaccess, Nginx의 nginx.conf)이나 애플리케이션 코드 내에서 설정할 수 있다. 예를 들어, 모든 프레임 삽입을 차단하려면 X-Frame-Options: DENY 헤더를 응답에 포함시키면 된다. 이는 OWASP가 권장하는 보안 조치 중 하나이다.

현대적인 웹 보안에서는 X-Frame-Options 대신 Content Security Policy의 frame-ancestors 지시어를 사용하는 것이 권장된다. CSP는 더욱 세밀한 제어가 가능하고 X-Frame-Options가 지원하지 않는 여러 시나리오를 다룰 수 있기 때문이다. 그러나 여전히 많은 사이트에서는 하위 호환성을 위해 두 헤더를 함께 사용하기도 한다.

Referrer-Policy는 브라우저가 다른 사이트로 이동할 때, 요청 헤더의 Referer 필드에 얼마나 많은 출처 정보를 포함시킬지를 제어하는 HTTP 응답 헤더이다. 이 정책을 통해 사용자의 탐색 습관이나 세션 식별자와 같은 민감한 정보가 의도치 않게 제3의 사이트로 유출되는 것을 방지할 수 있다. 이는 개인정보 보호와 정보 유출 방지에 중요한 역할을 한다.

Referrer-Policy는 여러 가지 지시어를 제공한다. no-referrer는 어떠한 Referer 헤더도 전송하지 않도록 하며, same-origin은 동일한 출처로의 요청에만 Referer를 보낸다. strict-origin은 프로토콜, 호스트, 포트만 포함하되, 보안이 낮은 사이트로는 정보를 보내지 않는다. strict-origin-when-cross-origin은 교차 출처 요청 시에는 출처 정보만을, 동일 출처 요청 시에는 전체 URL을 포함하는 등 다양한 수준의 제어가 가능하다.

이 정책은 주로 개인정보 보호를 강화하고, URL에 포함될 수 있는 세션 토큰이나 기타 민감한 데이터가 로그 분석 서비스나 제3자에게 노출되는 위험을 줄이는 데 목적이 있다. 또한, 사이트 관리자가 불필요한 정보 유출 경로를 차단함으로써 웹 보안 전반을 강화하는 데 기여한다. 적절한 Referrer-Policy 설정은 OWASP가 권고하는 보안 모범 사례의 일환으로 간주된다.

Permissions-Policy는 이전의 Feature-Policy 헤더를 대체하는 HTTP 응답 헤더이다. 이 정책은 웹사이트가 브라우저의 특정 기능과 API를 어떻게 사용할 수 있는지를 선언적으로 제어한다. 이를 통해 개발자는 사이트의 보안과 개인정보 보호를 강화하고, 사용자 경험을 일관되게 유지하며, 악의적인 코드가 민감한 기능에 접근하는 것을 방지할 수 있다.

Permissions-Policy는 카메라, 마이크, 지리적 위치 정보, 자동 재생, 전체 화면 모드 등 다양한 브라우저 기능의 사용을 허용하거나 차단할 수 있다. 예를 들어, 'geolocation' 기능을 'self'로 설정하면 동일 출처에서만 위치 정보 접근이 가능하고, 'none'으로 설정하면 완전히 차단된다. 이는 사용자 프라이버시를 보호하고, 예상치 못한 동작을 방지하는 데 중요한 역할을 한다.

이 헤더는 웹 애플리케이션의 보안 모델을 강화하여, 제3자 iframe이나 삽입된 스크립트가 사용자의 허가 없이 특정 기능을 사용하는 것을 막는다. OWASP가 권장하는 보안 헤더 중 하나로, 클릭재킹이나 정보 유출과 같은 공격을 완화하는 데 기여한다. 설정은 서버 구성 파일이나 애플리케이션 코드에서 HTTP 응답 헤더로 추가된다.

헤더 보안 정책은 주로 웹 서버 측에서 HTTP 응답 헤더를 구성함으로써 적용된다. Apache HTTP Server와 Nginx 같은 주요 웹 서버 소프트웨어에서는 설정 파일을 수정하여 필요한 보안 헤더를 전역적으로 추가할 수 있다. 예를 들어, Apache의 경우 .htaccess 파일이나 httpd.conf 파일에 Header set 지시어를 사용하며, Nginx에서는 add_header 지시어를 사용한다. 이 방법은 서버에서 제공하는 모든 정적 리소스에 일관된 보안 정책을 적용할 수 있다는 장점이 있다.

애플리케이션 서버나 백엔드 프레임워크를 사용하는 경우에도 헤더를 설정할 수 있다. Node.js의 Express, Python의 Django나 Flask, Java의 Spring Security 등 대부분의 현대 웹 프레임워크는 미들웨어나 설정을 통해 보안 헤더를 쉽게 추가하는 기능을 제공한다. 이는 애플리케이션 로직에 따라 더 세밀한 제어가 가능하지만, 프레임워크별 구현 방식에 차이가 있다.

설정 후에는 반드시 실제 응답 헤더가 올바르게 전송되는지 확인하는 과정이 필요하다. 브라우저의 개발자 도구 네트워크 탭이나 온라인 헤더 검사 도구를 이용해 Content-Security-Policy, Strict-Transport-Security 등의 헤더 존재 여부와 값을 점검해야 한다. 잘못된 설정은 웹사이트 기능을 오작동시킬 수 있으므로, 테스트 환경에서 충분히 검증한 후 운영 환경에 배포하는 것이 중요하다.

애플리케이션 코드 내에서 HTTP 응답 헤더를 설정하는 방식은 웹 서버의 구성 파일을 직접 수정하지 않고도 보안 정책을 유연하게 적용할 수 있는 방법이다. 주로 웹 애플리케이션 프레임워크나 미들웨어를 사용하여 구현하며, 특정 라우트나 전역적으로 헤더를 추가할 수 있다. 이 방식은 개발 주기에 통합하기 쉽고, 환경(개발, 스테이징, 운영)에 따라 다른 정책을 적용하는 데 유리하다.

대표적인 프레임워크에서는 미들웨어나 필터를 제공하여 손쉽게 보안 헤더를 추가할 수 있다. 예를 들어, Node.js의 Express에서는 helmet 미들웨어를, Python의 Django에서는 django.middleware.security.SecurityMiddleware를, Spring Security에서는 HeaderWriterFilter를 사용한다. 이러한 도구들은 Content-Security-Policy, X-Frame-Options, Strict-Transport-Security 등의 주요 보안 헤더를 기본값이나 사용자 정의 값으로 설정한다.

애플리케이션 코드에서 설정할 때는 보안 정책의 세부 내용을 정확히 이해하고 구성해야 한다. 특히 CSP는 허용할 스크립트 출처나 스타일시트 출처를 명시적으로 정의해야 하므로, 애플리케이션이 사용하는 외부 CDN이나 인라인 스크립트를 고려하여 정책을 작성한다. 잘못된 구성은 웹사이트의 정상적인 기능을 방해할 수 있다.

이 방식의 장점은 버전 관리 시스템을 통해 보안 설정의 변경 이력을 추적할 수 있고, 지속적 통합 및 지속적 배포 파이프라인에 보안 정책 검증을 포함시키기 용이하다는 점이다. 단, 애플리케이션 계층에서 처리되므로 리버스 프록시나 로드 밸런서를 거치는 경우 해당 계층에서도 헤더가 덮어쓰지 않도록 주의해야 한다.

클릭재킹은 사용자가 의도하지 않은 동작을 하도록 속이는 공격 기법이다. 공격자는 투명한 프레임이나 레이어를 사용해 악성 페이지 위에 정상적인 웹 페이지를 덧씌운다. 사용자는 보이는 정상 페이지를 클릭하지만, 실제로는 숨겨진 악성 페이지의 요소를 조작하게 되어 권한 상승이나 데이터 유출과 같은 피해를 입을 수 있다.

이를 방어하기 위한 핵심 HTTP 응답 헤더는 X-Frame-Options와 Content-Security-Policy의 frame-ancestors 지시어이다. X-Frame-Options 헤더는 DENY, SAMEORIGIN, ALLOW-FROM 값을 사용하여 페이지가 특정 출처의 프레임 내에서만 로드되도록 제한한다. DENY는 모든 프레임 삽입을 차단하는 가장 강력한 설정이다.

보다 현대적이고 세밀한 제어를 위해서는 Content Security Policy의 frame-ancestors 지시어를 사용하는 것이 권장된다. 이 지시어는 페이지를 포함할 수 있는 상위 프레임(부모, 조상)의 출처를 명시적으로 지정한다. 예를 들어, frame-ancestors 'self';는 동일 출처의 페이지에서만 프레임 삽입을 허용하며, frame-ancestors 'none';은 모든 프레임 삽입을 금지한다. X-Frame-Options 헤더와 동시에 사용될 경우, Content-Security-Policy의 frame-ancestors 설정이 우선 적용된다.

클릭재킹 방어는 웹 애플리케이션 방화벽이나 서버 설정을 통해 전역적으로 적용할 수 있으며, 자바스크립트를 이용한 프레임 브레이킹 스크립트를 보조 수단으로 활용하기도 한다. 그러나 클라이언트 측 스크립트는 브라우저 설정에 의해 비활성화될 수 있으므로, 서버 측에서 HTTP 헤더를 통해 보안 정책을 강제하는 것이 가장 효과적인 방어 방법이다.

XSS 방어는 헤더 보안의 핵심 목표 중 하나로, 크로스 사이트 스크립팅 공격으로부터 웹 애플리케이션과 사용자를 보호한다. XSS는 악의적인 스크립트를 웹 페이지에 삽입하여 다른 사용자의 브라우저에서 실행되게 하는 공격으로, 세션 하이재킹이나 개인정보 탈취 등 심각한 피해를 초래할 수 있다. 이를 방지하기 위해 서버는 특정 HTTP 응답 헤더를 설정하여 브라우저의 동작을 제한한다.

XSS 방어에 가장 효과적으로 활용되는 헤더는 Content Security Policy이다. CSP는 웹 페이지가 로드할 수 있는 리소스의 출처를 명시적으로 제한하는 정책으로, 인라인 스크립트의 실행을 차단하거나 신뢰할 수 있는 도메인에서만 스크립트를 로드하도록 강제할 수 있다. 이를 통해 공격자가 악성 스크립트를 주입하더라도 브라우저가 이를 실행하지 못하도록 막는다.

또한, X-Content-Type-Options 헤더를 nosniff로 설정하면 브라우저의 MIME 스니핑 동작을 방지할 수 있다. 이는 서버가 선언한 콘텐츠 타입을 브라우저가 임의로 추측하여 변경하지 못하게 함으로써, 스크립트 파일로 위장한 악성 데이터가 실행되는 것을 차단하는 데 도움이 된다.

이러한 헤더 기반 방어는 웹 애플리케이션 방화벽이나 입력값 검증 같은 서버 측 보안 조치를 대체하는 것이 아니라, 다층 방어 체계를 구성하는 보조 수단으로 작동한다. OWASP에서도 심각한 보안 위협으로 꼽는 XSS에 대한 효과적인 완화 조치로 헤더 보안 정책의 적용을 권고하고 있다.

MIME 스니핑은 웹 브라우저가 서버가 제공한 MIME 타입을 무시하고, 파일의 실제 내용을 검사하여 콘텐츠 유형을 추측하는 동작을 말한다. 이는 본래 호환성을 위해 설계된 기능이지만, 악의적으로 조작된 파일을 브라우저가 잘못 해석하게 만들어 크로스 사이트 스크립팅과 같은 공격을 유발할 수 있는 보안 취약점으로 악용될 수 있다.

이를 방어하기 위한 핵심 헤더는 X-Content-Type-Options: nosniff이다. 이 헤더를 설정하면 브라우저는 서버가 Content-Type 헤더에 명시한 MIME 타입을 신뢰하고, 파일 내용에 기반한 MIME 스니핑을 수행하지 않도록 지시한다. 이는 특히 스타일시트(text/css)나 실행 가능한 스크립트(application/javascript)와 같은 중요한 리소스에 대한 잘못된 해석을 방지하는 데 효과적이다.

MIME 스니핑 공격은 악성 코드가 포함된 이미지나 PDF 파일 등을 정상적인 콘텐츠로 위장하여 업로드하고, 브라우저가 이를 HTML이나 자바스크립트로 잘못 인식하게 만드는 방식으로 이루어진다. nosniff 헤더는 이러한 위장을 무력화시켜, 브라우저가 지정된 타입 외에는 다른 방식으로 리소스를 렌더링하지 못하게 막는다.

따라서 X-Content-Type-Options 헤더는 웹 애플리케이션의 방어 계층을 강화하는 필수적인 보안 조치 중 하나로, OWASP가 권장하는 보안 헤더 목록에 포함된다. 모든 정적 리소스와 API 응답에 이 헤더를 적용하는 것이 좋다.

정보 유출 방지는 민감한 정보가 의도치 않게 공격자에게 노출되는 것을 방지하는 것을 목표로 한다. 웹 애플리케이션은 다양한 경로를 통해 정보를 유출할 수 있으며, 적절한 HTTP 응답 헤더를 설정함으로써 이러한 위험을 크게 줄일 수 있다.

주요 정보 유출 경로 중 하나는 Referer 헤더이다. 이 헤더는 사용자가 어떤 페이지를 거쳐 현재 페이지에 도달했는지를 나타내며, URL에 포함된 세션 ID나 기타 민감한 정보를 외부 사이트에 노출시킬 수 있다. Referrer-Policy 헤더를 사용하면 브라우저가 Referer 헤더를 어떻게 전송할지 제어할 수 있다. 예를 들어, strict-origin-when-cross-origin 정책은 동일 출처 요청 시에는 전체 URL을, 다른 출처로의 요청 시에는 출처(도메인)만을 전송하도록 하여 불필요한 정보 노출을 방지한다.

또 다른 중요한 헤더는 Permissions-Policy이다. 이 헤더는 웹 브라우저의 특정 기능과 API(예: 카메라, 마이크, 지리적 위치 정보)에 대한 접근을 제한할 수 있다. 이를 통해 악의적인 사이트가 사용자의 허가 없이 민감한 장치나 데이터에 접근하는 것을 차단하여, 사용자 프라이버시 보호와 정보 유출을 방지하는 데 기여한다. 이 외에도 Server 헤더나 X-Powered-By와 같은 헤더를 제거하거나 최소화하여 백엔드 기술 스택 정보를 숨기는 것도 공격자의 정보 수집을 어렵게 하는 기본적인 방어 수단이다.